Hi, thanks very much for your PR, indeed print_above was written before using prompt toolkit and as I had not seen any bad behaviour I had not changed it.

I have just a little annoyement when using it, channel echoes does not handle emojis correctly. Some of those characters are larger and to accomodate with that I force the position from where path and signal strength are printed.

It should look like :

but with your PR it looks like

cursor moving is done here :

using this part of the formated string : {ANSI_START}{width-11-len(event.payload['path'])}G

If you get this working again, I'll merge the PR ;)

OK, great, on my terminal I don't get the [5f] 14.00 -80 right-aligned, in fact, I might not see it at all, is there an option you use to show this, or should it be standard?

I'll see if I can fix the problem. Originally the code split long lines into multiple, but I didn't bother with that, maybe this is causing that behavior

set channel_echoes on activates the channel echoes features, which displays all channel messages received from rx_log with path, snr and rssi

this is handy to follow repeats from the repeaters

I tried to fix the right-aligned texts now. You might find incidental over-compensation in the case of wide-characters in node names, but that is probably better than characters spilling over into the next line.

BTW I do see the benefit of the channel echoes, although in my case incoming traffic usually are a few echoes between the same few repeaters in my area --- but I can see that my repeater picks up the most messages

Hi, I'd suggest you to calculate the position of the cursor by calculating the size of the right aligned text (which only depends on the path length and should not contain emojis) and substracting this from the width of the terminal, this has proven more robust for me

Sadly I don't have much time right now :(

Hi,
It still doesn't work for messages with emojis.
Here is what I have with your PR :

While with current implementation:

The solution I use to make it work, is to move cursor on the line to the exact position where I want the path to start (because emojis don't have a fixed width and displaying them isn't even predictable depending on the terminal and/or the font)

Hi, I'll see if I can test with wide characters in messages. What platform did you use for those screen shots? I always run with -C because the non-unicode glyphs screw up my terminal.

Also I see that some unrelated changes got pushed to this branch, I'll see if I can undo these

On the mac terminal (with -C) it seems to work for me, with wide chars in user names and message

Hi, I'm on Linux and the result is consistent between terminal emulators (the screenshot has been made using foot)
I'm not surprised by the incompatibility of mac terminals, they probably do it on purpose ;)

is \033[<n>G not working on macs too ?

I've seen that macs are not the only platform where there is issue with print_above, I've tried to use a node through ssh with connectbot on an Android phone and messages were printed on the top of the window

I would be curious how the linux terminals work with the -C option, as that is the condition under which I develop. Typically I have some mac terminal at the UI, and then some ssh / tmux combo to a linux box which runs the meshcore-cli.py.

is \033[<n>G not working on macs too ?

I've seen that macs are not the only platform where there is issue with print_above, I've tried to use a node through ssh with connectbot on an Android phone and messages were printed on the top of the window

I think the analysis of the AI was that the mix of ansi escape sequences with prompt_toolkit was probably not great. I don't know what \033[<n>G exactly does, it would probably work all right I expect. I can imagine that these escape sequence semantics are less well defined in combination with wide characters, but this is just a hunch.

well, with -C it does not change anything to the output, which is logical because here -C only affects the prompt (it also affects the traces display)

here is mainstream mccli

here is your pr

Using ssh/tmux over your terminal does not change the way your terminal handles ansi sequences, that's why it doesn't change anything ... I'm using mccli daily through ssh (to access remote nodes in france), don't use tmux but screen has been working for me too

Please, don't send PR generated with AI, you can run AI on the code and get inspiration, but it generally modifies the code out of the scope of what is wanted (and I now understand some rewrites in your code that was not necessary). So take your inspiration, and then write the code exactly as you wish it to be ...

Yes it is true that mixing prompt-toolkit and ansi might be bad in some cases. The print_above code was introduced before I use prompt toolkit and if there are some prompt-toolkit bits to do it I'm good with it. but for the moment, the text alignment method I've been using is better (because I don't have to guess the width of the characters)

also, have you tried and ansi-compliant terminal emulator on your mac ? I see there is alacritty available, which works just fine for me on Linux.

I'm not asking to avoid making the change, but just so you see how it "should" look

Also, when I wrote about the fact that print_above has been introduced before the use of prompt-toolkit (and as it was meant as a mechanism for dealing with the prompt), the idea came to me that maybe I don't even need print-above now, surely prompt-toolkit directly handles output in the terminal while typing in the prompt ... will test that, it might be a lot simpler than I thought !

OK, thanks, this is clear. I will close this PR, as it is too hard to develop between Linux/mac terminals at the moment.

I would not normally submit AI code, but see the disclaimer in my original message, and I would normally write code for Linux, not for other OSs. But circumstances were a little different this time, sorry about all that.

I'll keep this as a working branch for myself, as this originally grew out of garbled terminals on my side.

Cheers!

no problem,

I'll try to refactor the whole print_above thing, and will probably re-read your code to get some ideas ...

Can I ask you for testing under mac when I have something ?

that was so easy, just use patch_stdout and there is no need for print_above anymore !

            with patch_stdout(raw=True):                                                                                                                                                       
                line = await session.prompt_async(ANSI(prompt),
                                              complete_while_typing=False,
                                              completer=completer,
                                              key_bindings=bindings)

@davidavdav can you test please ?

from the refactor-print-above branch

https://github.com/meshcore-dev/meshcore-cli/tree/refactor-print-above

if it works then its a very welcome simplification ;)

I try a few wide chars messages, and it seems to work for me now, with channel_echos on and timestamps and snr, and wide chars in messages. No problems with garbled command line anymore...

Thanks!

Well, let me thank you too, because I wouldn't have thought about it ... this is so much better now ;)

and thanks for reporting back quick too !